This could not be merged since it introduces even worse scenarios. With this change, it would not work with more than one consumer at all.

for example here you migrate all message and that would work for one consumer but fail for more.

If you need strict message delivery guarantee than I'd suggest you to use a real broker such as RabbitMQ or AmazonSQS.

We've investigated the issue at our end looking for a solution to fix it. Unfortunately, we've not come with any better approach. The current one is not ideal but it remains the best one

This could not be merged since it introduces even worse scenarios. With this change, it would not work with more than one consumer at all.

for example here you migrate all message and that would work for one consumer but fail for more.

https://redis.io/commands/renamenx would work for multiple consumer isn't it? If 1 consumer successful migrate messages, other consumers trying to migrate would result returns an error when key does not exist or 0 if newkey already exists..

With the added logic its probably slower and have duplicated messages. In our production we have been running this for a while with ~15 workers, no message lost so far (given redis is not down)

If you need strict message delivery guarantee than I'd suggest you to use a real broker such as RabbitMQ or AmazonSQS.

We've investigated the issue at our end looking for a solution to fix it. Unfortunately, we've not come with any better approach. The current one is not ideal but it remains the best one

I would suggest dropping this library altogether for next project.

When someone picks a message queue library they are probably expecting at least once delivery. Any pitfalls should have been mentioned in readme and drop the “battle tested, production ready” bs.

Just a friendly reminder, you got a couple of years of several developers work for free

and I have to spend my free unpaid time to review your PR and dig into details, which is not always easy and takes a considerable amount of time.

You could release your version as a standalone package. I would gladly accept a PR for the doc that describes current implement limitations and possible message lost. It could contain a link to your package too.

If time proves your approach is better it could be merged here.

For now, I don't have enough resources to go through this PR and be sure it does not break anything

Thanks. The PR is clearly unfinished and tests are failed, of course I am not expecting this to be merged any time soon. Neither do I have time to polish it good enough for general release.

We had problems and we have attempted to fix it. I just though it was a good idea to share the progress and directions though. The source here is exactly the same as what we are currently running.

@cshum fyi #770